Electronic device manufacturers use nanometer-level semiconductor fabrication processes to manufacture integrated circuits with reduced geometries sizes, thereby providing more transistors and interconnection resources per unit area. But manufacturing devices in increasingly smaller geometries also increases the presence of conductor-related failures and resistive-type defects. Conductor-related failures generally arise from process variations that degrade the quality of metallic interconnects, resulting in inconsistent contact resistances, for example. Resistive defects cause signal transitions to rise and fall more slowly at affected circuit nodes. But since traditional stuck-at and parametric leakage current (e.g., IDDQ test) test methods cannot effectively detect these types of faults, electronic device manufactures commonly rely on delay testing methodologies to screen out such failure modes. Structural delay tests, however, are noticeably more expensive than traditional test approaches, such as the stuck-at test. For example, the volume of data to implement delay tests is significantly greater than the volume of data for traditional stuck-at tests. In some cases, delay tests require three to five times more data than the stuck-at tests. Further, stuck-at tests detect static faults, such as a circuit node being “stuck at” a logic value of either 1 or 0. By comparison, delay tests detect dynamic faults that cause signals to either rise or fall more slowly than is acceptable. Generally, delay tests require propagation of a transitional signal through a circuit in which the test screens for delay-related faults. And since delay tests require the launch and the capture of the transition signal within certain timing constraints, delay test vectors are significantly more difficult to generate and synchronize with a test clock than stuck-at test vectors.
FIG. 1 is a diagram showing a portion 100 of a scan chain commonly used to implement conventional delay tests for detecting dynamic-related faults in a circuit under test (“CUT”) 102. Conventional scan chains generally include flip-flops 108 and multiplexers 106. A scan enable (“SE”) signal 104 controls multiplexers 106 either for exchanging stimulus and result signals with circuit 102, or for shifting scan data into or out of flip flops 108. Traditionally, scan enable 104 is a global signal that propagates from a single source through a fan-out arrangement, similar to test clock (“CLK”) 120. Scan in terminal (“SI”) 110 accepts scan data from an external source, such as automatic test equipment (“ATE”), whereas scan out terminal (“SO”) 112 shifts out the results generated by the stimulus signals. To orchestrate a delay test using scan chain portion 100, test clock generators usually generate a test clock (“CLK”) 120 to drive the scan data through a scan chain. A multiplexer 130 gates either a slow clock 140 or a fast clock 150. Specifically, scan chain portion 100 uses slow clock 140 for driving scan data through the scan chain, and uses fast clock 150 for performing at-speed functional test on circuit 102. While ATEs can operate as test clock generators, on-chip functional clock circuits, such as on-chip phase-locked loop (“PLL”) circuits, can offer high-speed test clock signals at lower costs. But conventional test clock generation circuits are complicated and costly, especially when a device under test (“DUT”) contains many clock domains, such as 20 to 100 clock domains, or more.
FIG. 2 illustrates the timing uncertainties arising from the use a single scan enable (“SE”) signal to perform traditional at-speed delay tests in conventional scan chain structures. One example of an at-speed delay test commonly used for detecting dynamic faults is the “last-shift-launch” test. In this technique, the last scan data bit shifted into a scan chain for a first test pattern becomes an input of a second test pattern after one more shift. Timing diagram 200 shows test clock 120 and scan enable 104 signals of FIG. 1 performing a traditional last-shift-launch test. In particular, the first test pattern is shifted into a scan chain using slow clock 140 during scan mode, with the last scan data bit shifted into the scan chain as launch edge 210. To perform the at-speed delay test, scan enable 104 changes state along with the application of fast clock 150 to the scan chain to capture the functional test result. A drawback to using single scan enable signal 104 for implementing at-speed delay tests is that the detection of capture edge 220 must be within a defined interval of time, thereby imposing an at-speed timing constraint 202. Therefore, scan enable 104 must transition from one state to the next during at-speed timing constraint 202 to adequately detect capture edge 220. But it becomes difficult to expect scan enable 104 to adequately transition states as at-speed timing constraint 202 increasingly narrows to accommodate delay tests on smaller geometries.
FIG. 3 illustrates a typical scan chain structure 300 using conventional test clock control techniques to effect at-speed delay tests. As shown, scan chain structure 300 includes scan chain 320 having a scan input 310 and a scan output 312, as well as an internal clock generator 330 (e.g., one or more PLL circuits) and an internal test clock controller 340. Scan chain structure 300 uses internal test clock controller 340 to perform at-speed delay tests on circuits under test (“CUT”) 302. Each circuit under test 302 resides in a clock domain 304. A clock domain is a region of circuitry that is synchronized with a particular clock. Clock control bits 350 define the operation of internal test clock controller 340. But to configure internal test clock controller 340, traditional at-speed test techniques embed clock control bits 350 into a scan chain 320 along with scan data bits. A drawback to this approach is that scan chain 320 is loaded with clock control bits 350 to test one clock domain 304 per scan chain loading. Thus, the entire scan chain 320 is loaded and unloaded every time a separate domain 304 is tested. Note, too, that clock control bits 350 are static, especially during testing. Specifically, scan chain structure 300 generally requires clock control bits 350 to remain immobile in scan chain 320 so that internal test clock controller 340 can operate according to those bits. As such, scan chain structure 300 and other similar conventional scan chain structures are not well-suited to operate internal test clock controller 340 independent of the bits in scan chain 320, especially when implementing inter-clock domain tests (e.g., launch and capture). Another drawback is that traditional scan chain structure 300 is generally inadequate to support control sequences and/or programs that control the selective loading and unloading of portions of scan chain 320 for purposes of reducing test time and data volume. For example, most scan chains 320 cannot selectively reload scan chain 320 (or one or more portions thereof) to test only targeted circuits under test 302. This means that scan chain 320 is likely loaded with data that is non-essential to a particular test, whereby the non-essential data loaded into scan chain 320 increases test data volume, which, in turn, increases test time. To examine the results of one of targeted circuits 302, traditional scan chains 320—which tend to be relatively lengthy—requires shifting both non-essential data and resultant, the combination of which contributes to generally long test times. Yet another drawback to scan chain structure 300 is that inter-domain logic 306 is generally inadequate to sufficiently synchronize a capture clock pulse in one clock domain with a launch clock pulse from another clock domain, especially when both clock domains have different clock frequencies.
FIG. 4 illustrates the testing of inter-domain logic 306 using the scan chain structure 300 of FIG. 3 using conventional test clock control techniques. Typically, a transition from logic 0 to 1 (or vice versa) is launched from an output register (“OutReg”) 402 in a first clock domain (“i”) 410 to an input register (“InReg”) 404 of a second clock domain (“j”) 420. Clock (“CLK[i]”) 412 drives the transition from output register 402 via inter-domain combinational logic 306 to input register 404, which operates at clock (“CLK[j]”) 422 to latch the state of the transition. A desired launch edge 450 provides for synchronicity of a capture edge 470 to properly capture a test response. But consider that one clock period for clock 422 corresponds to five clock periods of clock 412. If a transition is launched from clock domain 410 in synchronization with clock edge 460 for clock 422 (in clock domain 420), as is normally done in conventional delay tests, then five clock periods can elapse before the test response is captured within clock domain 420. Thus, the unintended launch at edge 440 may not properly capture a test response at edge 470. Managing synchronization among clock domains in conventional scan chain structures becomes increasingly difficult as the number of participating clock domains increases. In addition, latency inherent in traditional internal test clock controllers can complicate inter-clock domain testing for similar reasons.
FIG. 5 is a block diagram 500 depicting an internal test clock controller 502 having a conventional test functional clock path 530 for implementing at-speed delay tests. Internal test clock controller 502 receives a functional clock (“PLL Clk”) 510 and embedded clock control bits 504 to generate delayed capture pulses. Internal test clock controller 502 also includes a pulse counter 520 to count the edges of functional clock 510, and logic 522 to generate a test clock 550 in response to the values of embedded clock control bits 504. In operation, pulse counter 520 and logic 522 cooperate to delay a capture pulse 570 after a launch pulse 560 by a delay 562 to perform, for example, inter-domain testing. A drawback to this approach is that internal test clock controller 502 includes a test functional clock path 530, which includes additional circuit elements other than a multiplexer 534. These additional elements 536 can detrimentally skew at-speed functional clock signal 510 when performing launch and capture operations, resulting in uncertainty 580 in the timing of capture pulse 570. Usually, delay 562 requires clock balancing to guarantee that an at-speed functional clock over path 530 in test mode can mimic functional clock 510 in run mode (e.g., when test mode, or TM, is disabled) over path 532, which does not include additional elements 536.
FIGS. 6A and 6B depict traditional implementations for broadside and last-shift-launch test protocols, respectively. FIG. 6A includes a scan chain 610 including various registers stages 612. For broadside protocol testing as shown in diagram 600, a desired transition 602 is launched from a previous register stage 612b to propagate through a combinational circuit 620b, and then captured in register 630 in the register stage 612c. This tests—directly or indirectly—combination circuits 620a and 620b. During a launch edge, register 632 latches a logical 0, thereby launching a 1-to-0 transition through combinational circuit 620b. Register 630 captures the logical 0 value at a capture edge. Note that the presence of logical 0 depends on a prior transition 601 from the value in register 634, thereby testing combinational circuit 620a. In this technique, an entire scan chain is loaded with data by shifting it in at slow speeds in test mode, followed by the two at-speed clocks pulses (e.g., the launch and capture edges) in functional mode. Then once the values are captured, the data can be shifted out slowly in test mode. While a delay test using the broadside protocol can detect otherwise undetectable delay faults, the size of test patterns for broadside protocols is usually larger than pattern for last-shift-launch protocols. Further, the test patterns for broadside are sequential in nature and thus are more difficult to generate.
FIG. 6B includes a scan chain 660 including various registers stages 672. For last-shift-launch protocol testing, a transition 662 is launched from the last shift during a scan load or unload sequence in register stage 672b. It is then captured into register 680 in next register stage 672c. Since input transition 690 is launched from the last shift 661, pattern sizes for last-shift-launch tests can be smaller and easier to generate than that of broadside because sequential test patterns are more difficult to compress than combinational patterns. But the last-shift-launch protocol suffers from the drawbacks described above. Since both broadside and last-shift-launch both seemingly have mutually exclusive advantages and disadvantages, most designers implement either only one or the other.
In view of the foregoing, it would be desirable to provide systems, structures and methods that minimize the above-mentioned drawbacks and provide for at-speed scan-based testing to at least detect delay-related faults.